Transactional computer system

ABSTRACT

A transactional computer system comprises a plurality of entities including at least one entity of each of the following forms, a Thing entity having the properties of identifying a client system and uniquely identifying an object in that client system, a Proposal entity for defining a transaction, the Proposal entity being subordinate directly or indirectly to a Thing entity and having the properties of modelling at least one external agent to carry out a transformation in relation to the first entity, and a Decision entity capable of communicating with a Proposal entity and having the properties of defining the types of decision that may be made, and determining the responses in relation to those decisions. The system preferably further comprises at least one Assignment entity subordinate to an associated Thing entity, the Assignment entity having the properties of uniquely identifying the associated Thing entity, and identifying a particular type of assignment or transformation to be applied to the Thing entity. This entity may be combined with the Proposal entity. Additionally the computer system preferably comprises at least one Tender entity associated with a plurality of Proposal entities and a single Thing entity, and identifying at least a quantity.

BACKGROUND OF THE INVENTION

This invention relates to a transactional computer system, namely acomputer system adapted to perform negotiation and decision makingfunctions related to a transaction.

Transactional computer systems are known for use in the financial andbusiness world for conducting transactions such as, for example,ordering product, currency exchange, or the sale and purchase of stock,shares and bonds. Such systems are designed specifically for theparticular function or functions which they are to perform.

Rule-based systems using what is generally known as artificialintelligence are also known. These are based on a large number of ruleswhich are specific to the particular environment in which they are to beused. A given system is designed for a particular type of transaction,and if a new type of transaction is envisaged a new system will have tobe designed specifically for that purpose.

I have appreciated that it would be highly desirable to provide ageneralised transactional system which can be adapted to many specifictypes of transaction, and furthermore I have appreciated that such ageneralised transactional computer system can be made by using the ideasand features described in the following and claimed in the claimsappended to this description.

SUMMARY OF THE INVENTION

The invention is defined in the independent claims below to whichreference should now be made. Advantageous features are set forth in theappendant claims.

According to the present invention there is provided a transactionalcomputer system comprising a plurality of entities including at leastone entity of each of the following forms, a first entity (Thing entity)having the properties of identifying a client system and uniquelyidentifying an object in that client system, a second entity (Proposalentity) for defining a transaction, the second entity being subordinatedirectly or indirectly to a first entity and having the properties ofmodelling at least one external agent to carry out a transformation inrelation to the first entity, and a third entity (Decision entity)capable of communicating with a second entity and having the propertiesof defining the types of decision that may be made, and determining theresponses in relation to those decisions.

Preferably the computer system further comprises at least one fourthentity (Assignment entity) subordinate to an associated first entity,the fourth entity having the properties of uniquely identifying theassociated first entity, and identifying a particular type of assignmentor transformation to be applied to the first entity. This entity may becombined with the second entity.

Additionally the computer system preferably further comprises at leastone further entity (Tender entity) associated with a plurality of secondentities and a single first entity, and identifying at least a quantity.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be described in more detail by way of example,with reference to the drawings, in which:

FIG. 1 illustrates the hierarchical structure of the entities in apreferred computer system embodying the invention;

FIG. 2 is a flow chart illustrating the NewEntity procedure in thepreferred embodiment of the invention;

FIG. 3 is a flow chart illustrating the RegisterEntity procedure in thepreferred embodiment of the invention;

FIG. 4 is a flow chart illustrating the LoadHierarchy procedure in thepreferred embodiment of the invention;

FIG. 5 is a flow chart illustrating the Math: AddDecision procedure inthe preferred embodiment of the invention;

FIG. 6 is a flow chart illustrating the Cube: Apply Decision procedurein the preferred embodiment of the invention;

FIG. 7 is a flow chart illustrating the Item(EntityKey) procedure in thepreferred embodiment of the invention;

FIG. 8 is a flow chart illustrating the Math: GetMathValue procedure inthe preferred embodiment of the invention; and

FIG. 9 is a flow chart illustrating the Cube: GetValue procedure in thepreferred embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

General Description

This system is embodied in a computer software module which, whenincluded in a client system, will capture the complexity of itsnegotiations, but leave the description of those transactions to theclient system. The system makes possible the management of thetransaction space in a straightforward and effective manner. It doesnot, however, manage the transaction space directly. Rather, it supportsthe modelling of the transaction space in a convenient and effectivemanner, and then, once modelled, it is for the client system to respondto the situations discerned and captured in the model. The power of thesystem is in its flexibility for modelling and managing the clientsystem's complex transaction space.

The system will only capture and supply information without using it forits own internal manipulation. It is better to record what people claim,and then leave the external clients/parties to resolve their claims,than it is to try to decide the truth of a matter. Consequently, thevalidity or otherwise of the supplied information has no bearing on thesystem. However, it may have a significant bearing on the satisfactoryuse of the system; therefore the client system should validate theinformation supplied and act accordingly.

The system comprises a hierarchy of entities: a Thing, a Proposal and aDecision, and optionally an Assignment and/or a Tender. Each entity typehas a set of properties appropriate to its role. These are described inmore detail below as part of the preferred embodiment. It is a featureof the system that an extension of the modelling environment can beachieved by the provision of additional properties per entity.

The Thing Entity

The system supports the modelling of the existence of external objectsby provision of a ‘Thing’ entity. In the preferred embodiment, the Thingentity has fields ClientSystem, and ClientSystemReference. TheClientSystem field is an identifier of the client system itself, and theClientSystemReference field is an identifier by which the implicitexistence of an object identified by that Reference is posited.

No validation as to the nature of that implicit object is eitherattempted or warranted, nor of any other information pertaining to theworld outside the system.

A ClientSystemReference to a Thing must be unique, so that allbehaviours and data to a common external thing will be mapped andmanaged by a common internal Thing. Client applications must ensure thatthey have implemented an appropriate nomenclature to ensure uniquereferences per client system.

The Assignment Entity

The system supports the modelling of assignments or transformationsapplied to external objects. It does so by provision of an ‘Assignment’entity. An Assignment, for the purposes of the system, is regarded as atransformation that may be applied to a Thing, for example an operationwhich can be conducted in relation to an object. Thus, in the system'sentity hierarchy, an Assignment is subordinate to and applies to aThing.

An Assignment will comprise in particular an identifier for theparticular type of assignment or transformation to be applied. This keyinformation is supplied by the external client system in theAssignment's ‘Redirection’ field, see below.

Timing of an assignment will often be significant to the externalclient. A facility to recognise timing may, if desired, be provided bythe inclusion of fields appropriate to each of the distinct entitytypes. In particular, fields relating to overall deadlines forAssignments may be included in that entity.

Linking Assignments

The system supports sequential modelling of assignments. As an example:with a Thing(CAR), Assignment(WASH) might be followed byAssignment(DRY). The assignment sequence is maintained by referring toWASH as the predecessor to DRY.

The Tender Entity

The client system is allowed to group together a set of proposals, thusallowing more complex negotiation behaviours to be modelled. Forexample, as its name implies, Tenders and auctions may be modelled. Thesystem allows the creation of the Tender entity and notes itscorresponding external reference.

The Proposal Entity

The system includes an important facility to model the existence ofagents to carry out the transformations. As an example this might be acleaning machine which is required to wash a car. This is supplied by a‘Proposal’ entity.

A client system wishing to identify the potential for an agent to impactan assignment's fulfilment will create a Proposal. Since in thepreferred embodiment the Proposal has a bearing on a particularAssignment, it is subordinate to an Assignment in the hierarchy and inthe preferred embodiment applies to a single Assignment only. Wherethere is no Assignment entity, a Proposal may be subordinate to a Thing;either way it is seen that a Proposal is subordinate directly orindirectly to a Thing.

The identification of an agent by a client system is at no timevalidated by the system, but is deemed to be supplied by the clientsystem as a rational and satisfactory identity.

The system provides for modelling situations where the potential actionof the agent may often have arisen as a matter of negotiation. Thecounter-party to the agent in this negotiation is also identifiable bythe client system.

The system includes a facility to distinguish the current direction ofthe negotiation.

The Proposal itself carries a rich set of features, sufficient andappropriate to the complexity of the environments it is intended to becapable of modelling.

The preferred embodiment supports the following features within aProposal, each being a field supporting input by the client system. Theidentity of the agent capable of impacting the Assignment is held in thefield ‘Downline’. The counterparty to the agent in this negotiation isheld in the field ‘Upline’. In regard to a specific proposal, the Uplinewill have no direct impact upon the Assignment. The direction of thenegotiation is implemented as a boolean flag ‘DirectionGoingUp’, whichmay be either true or false.

For example, a proposal going DOWN, whereby the party making theproposal is the Upline and expects a reply from the Downline, models arequest or command. Conversely, a proposal going UP, whereby the partymaking the proposal is the Downline and expects a reply from the Upline,models the function of volunteering.

A proposal is something to be considered and a decision made on it. Aproposal is therefore conveniently recorded using the expressionConsider.Do, as will be seen below.

As indicated above, a facility to recognise timing may be provided bythe provision of fields to reflect the same. Deadlines for making adecision, and for complying (completing an assignment) may be includedin the Proposal Entity.

Grouping Proposals

By grouping proposals it is possible to extend the flexibility of themodelling environment to support the tracking of complex interactions.For example, cause and effect, flow modelling, command and control andthe like, can be grouped. This grouping is accomplished by usingSubordinate Proposals and Sibling Proposals.

Subordinate Proposals

A further feature of the preferred system is the modelling ofsubordinate proposals. For example, in a factory, a Thing(CLIENTORDER)with an Assignment(FILL) may require a sequence of proposals before itcan be fulfilled. This may include the interaction of several people.These proposals should be grouped together. To achieve this theProposalID of the Superior proposal is recorded in all subordinateproposals using the field SuperiorProposalRefID.

Sibling Proposals

A further feature of the system is the grouping together of proposalsregarding the same matter. For example, if in a warehouse a customerwants 1000 ball bearings, but there is only 800 on the shelf, then 200will have to be refused. All of this information will be stored in manyproposals, but all regarding the same matter (i.e. the order for 1000ball bearings). To achieve this grouping all sibling proposal entitiesstore the original ProposalID in the field SiblingProposalRefID.

Combined Proposal/Assignment Entity

As described above, the assignment entity is optional. The features ofthe assignment entity, if included, may be combined with a proposalentity to provide a combined proposal/assignment entity which has theproperties of both a proposal entity and an assignment entity.

The Decision Entity

The system records the response from the counter-party in regard to acorresponding proposal. This is the role of the Decision Entity which issubordinate to and can communicate with a single one of the Proposals.Delegated proposals are tracked by passing the Decision for aSubordinate Proposal to the Superior Proposal. An individual position ina negotiation is tracked by passing a Decision for a Sibling Proposal toall the other Sibling Proposals with the same SiblingProposalRefIDfield.

The response recorded by the decision entity can be: decline, accept,partially accept, or forward. Forwarding involves accepting the proposalbut finding another agent actually to undertake it. The responses arerecorded in the form Decline.Do, or Accept.Do, and so on, asappropriate.

The Decision Schema

In order to derive effective meaning from the system, external decisionsneed to be recorded in a consistent, effective and intuitive manner. Theprotocol for so doing is implicitly provided by the creation of alogical structure, termed the decision schema. The decision schemacomprises multiple dimensions and defines what types of decision may bestored. Each dimension comprises a set of direct fields and a set ofderived fields:

-   -   Direct fields, define the types of decision that may be stored.    -   Derived fields summarise the consequences or impact of the        decision.

It is desirable that the direct fields represent a set of mutuallyexclusive states, whereas the derived fields need not be mutuallyexclusive. Each field is assigned an index into the dimension. Adecision type node is then defined as a vector, comprising one indexfrom each dimension. Decisions of that type have their quantitiesapplied to that node, so that each node accumulates a summary of likedecisions.

The Decision Schema is a facility which client applications may use tomodel complex negotiations in a manageable and effective manner. Aclient application must, however, be clear as to its decision semantics,in order to make use this feature. An example of a Decision Schema isgiven below in the more detailed description of the preferredembodiment.

The Decision Cube

A decision cube is built in the code in the form of a multidimensionalarray. It is used to store the quantities associated with each decision.Each element of the array should be initialised to zero.

Design Principles for Decision Schemas

Decision states (within a dimension) are exclusive. It is meaningless torecord both an agreement to NotDo something, and yet that it is Done. Ifan agent agrees to NotDo something, and yet declares it Done, then it isregarded in the context of the system as a rogue agent.

The decision cube does not preclude recording inappropriate ormeaningless information. As noted above, it is a fundamental designprinciple that it is better to record what people claim, and then leavethe external clients (or parties) to resolve their claims, than it is totry to decide the truth of a matter. Thus the system can record both aNotDo and a Done, and let the client system scan for such occurrences,and then implement whatever procedures necessary at that point.

Decision states may be partial. This requires the proposal to have aQuantity. For example: a proposal to ship 12 crates of water(Consider.Do.12) may have the response: Accept.Do.6, Decline.Do.4;leaving 2 undecided (Pending).

This also leads to a further observation: that a proposal using aQuantity is deemed to refer to a homogeneous assignment. Thus, withshipping bottles of water, it is assumed that the parties to theproposal are indifferent between two bottles of water from the sameassignment. If partial quantities need to be differentiated, then theyshould be differentiated as different Things, and then renegotiatedaccordingly. Thus a crate of 20 pieces of fruit (12 Apples and 8Oranges) is perfectly acceptable as a Thing, provided the system is notexpected to discriminate between Apples and Oranges. If it is, then itshould be registered as 2 shipments: one of Apples [Quantity 12], andthe second as Oranges [Quantity: 8].

Optional Entities

The entities Assignment and Tender are optional members of thehierarchy. Specifically a Proposal may be created for a Thing withoutrequiring an Assignment or Tender. This facility is provided to supportvery simple scenarios, without the overhead of the unnecessary creationof Assignment and Tender entities. The hierarchy will always includeThing, Proposal and Decision entities. This hierarchical structure isillustrated in FIG. 1.

Requirements

The basic requirements needed to support a physical implementation ofthe system are:

-   -   A facility to define the distinct Entities, their Properties,        and the Values associated with these Properties.

A facility to create the Entities.

A facility to have such Entities persist.

-   -   A facility to identify particular instances of Entities.    -   A facility to set, edit and retrieve the Property Values of such        Entities.

A facility to manipulate Entities in a Hierarchy.

The Preferred Embodiment

The processes required to implement the system will now be described inmore detail, including in particular the construction of the Entityhierarchy, and adding decisions to the hierarchy.

The specific functions (processes) described in more detail below are:

NewEntity( ) The facility to create a new member entity of the hierarchyRegisterEntity( ) The facility to load an entity (into memory)LoadHierarchy( ) The facility to load directly a full subordinate treeApplyDecision( ) The facility to increment the multidimensional dataarray, or cube Item( ) The facility to retrieve a pointer to a memberentity Cube: GetValue( ) The facility to retrieve a cube's value at aparticular node NotifyEvent( ) Advising Client System of an event

Of these functions, only two are intended to be accessible toclients/parties external to the system, namely NewEntity( ) and Item( ). The function LoadHierarchy( ) could be achieved by multipleapplications of RegisterEntity( ) but it is convenient to have itavailable as a separate function in its own right.

The only further facility required to provide an effective minimalembodiment of the system is then:

EntityPropertyValue( ): Retrieve the Value of a Property of an Entity.

This is a trivial process and need not be further discussed.

The utility of the system will often require a client application to beable to determine the state of a particular entity, by examining itsproperties. This function provides that facility.

The following describes the sequencing and sub-processes necessary tosupport each of the key function processes highlighted above. Thedescriptions should be read in conjunction with the flowcharts in FIGS.2 to 9 with the same title. Numeric references refer to theseflow-charts individually.

In the preferred embodiment of the system, the hierarchy consists ofThings, Assignments, Tenders, Proposals and Decisions. Since theirprocessing internal to the system is largely similar, it is moreconvenient to regard them all as instances of a generalised Entity. Animplementation of NewEntity( ) therefore may be read as “Construct afacility, of the type: NewEntity(EntityTypeName) where EntityTypeName isone of: Thing, Assignment, Tender, Proposal, Decision.”This allowsfurther hierarchies to be readily developed, but at the cost of moresophisticated code to handle the distinct types.

Notation: Numbers: 1. Numbered boxes in the accompanying flow-charts.Restrictions: [Thing only] Entities only of [this] type Exclusions: [NotThing] Entities not of [this] type Universal: [All] Entities of allTypes.NewEntity( )

This is the facility to create a new member entity of the hierarchy andis illustrated in FIG. 2 of the drawings. The procedure applies to allthe entities Thing, Assignment, Tender, Proposal, and Decision. Notehowever that Step 1 applies only to a Thing, Step 4 does not apply toDecision, and Step 5 applies only to Decision.

Arguments: The Properties of that Entity. See Entity Properties, Below.

-   1. [Thing only] A Client Reference to a Thing should be unique. A    check is made to see if such a Client Reference already exists.-   1a. If it does, the process is deemed to have failed.-   2. [All] Add a new record to the appropriate EntityType database    table. Include the data from the arguments to the NewEntity( ) call.-   3. Retrieve a unique ID (within that EntityType) for the new entity.-   4. Register( ) the new entity in memory, see below and FIG. 3.    (Create a new object in memory, of that type, with the appropriate    data as supplied by the arguments in the call to the function.)-   5. Proposal: Math: AddDecision( ), see below and FIG. 5. Since    something has happened which could have a bearing on the client    systems behaviour (e.g. a new Thing to be considered, new Assignment    to be processed, new Tender to be negotiated, Proposal to be    considered, or Decision to be evaluated), an EventNotification is    sent out to the client system to make it aware of the event, in    particular its type, and its ID. See NotifyEvent( )-   6. NotifyEvent( ). Finally, an ID is returned (non-zero, in this    embodiment), unique within the EntityType, so that the caller of the    process may subsequently refer to this particular new entity, in    calls to Item( ), by its new EntityName.    RegisterEntity( )

This is the facility to load an entity (into memory), and is illustratedin FIG. 3 of the drawings. The procedure also applies to all theentities Thing, Assignment, Tender, Proposal, and Decision. Note howeverthat Steps 2, 3, 4 and 6 do not apply to a Thing, Step 3 does not applyto Assignment, Step 7 does not apply to Decision, and Step 9 appliesonly to Thing.

Arguments: The properties of that Entity. See Entity Properties.

Arguments: In addition, the ID's of the Entity's superiors in theHierarchy.

-   1. A check is made, to discover whether this particular entity has    already been loaded. If so, there is no need to load it again.    Processing proceeds to Step 11, where a Pointer to the Entity is    returned, so that the calling function may directly reference its    properties.-   2. [Not Thing] Item( ): Get pointer to superior thing, see below and    FIG. 7. As the EntityType ‘Thing’, is the root of the Hierarchy    structure, all instances of subordinate EntityTypes (but not a Thing    itself, hence the exclusion) will have a superior Thing. This step    proceeds to get a reference to the entity's superior Thing, by a    call to Item(ThingID). The ThingID is passed, along with the ID's of    any other superior entities, in the call to the function. As a    further consequence of the call, since Item( ) will load the Thing    if not already loaded, it will load the full hierarchy particular to    this Thing, including the entity which is being attempted to be    registered. Hence this call is recursive if the Thing was not    already loaded. Thereafter, the Thing being loaded, there is no    further call to load the hierarchy, and hence to register the entity    which originated the call to Thing. In the recursive case, this    process again checks to see whether or not the subject of the    original call has now in the interim been loaded.-   3. [Not Thing, Not Assignment] This step calls Item( ) as required    to get pointers to further superior entities. A Thing has none, and    as Assignment has only a superior Thing, so both are excluded from    this step. These pointers will be used in Step 6, to allow an entity    to directly reference its superiors. This step also provides an    opportunity to ensure that the superiors specified in the call to    this function are all available, and appropriate to the entity being    registered.-   4. [Not Thing] See Step 2. Due to the recursive nature of the call    to Item(ThingID), this step checks to see whether the originally    requested entity has now in the interim been loaded in memory.-   5. [All] In this step, a blank (uninitialised, data unspecified)    instance of this class of entity is created in memory.-   6. [Not Thing] All objects other than a Thing will have superiors.    In this step, the pointers gathered in Steps 2 and 3 are now    assigned to appropriate properties in the new memory instance. In    this particular embodiment, only the immediate superior in the    hierarchy is assigned to the new memory entity. Higher superiors may    then be accessed by chaining entity properties, e.g.:    -   (Visual Basic) Proposal.Tender.Assignment    -   (C++) Proposal( )−>Tender( )−>Assignment( ).-   7. [Not Decision] Create and link a Math Crystal. This step assigns    the property values, passed as function arguments, to the    appropriate Object.Properties. Hereafter, a client system or    internal routine will be able to directly determine the state of the    object, by accessing these Property Values.-   8. Assign the Entity's data.-   9. [Proposal Only] A Proposal has a Property Quantity or more    exactly Consider Quantity. This is the amount that is being offered    for consideration. Where the field is not used or required, it may    be deemed to have a value 1. It is therefore meaningless to consider    the impact of decisions (how much has been agreed, etc.) if the    original target is not known. This step therefore adds a Decision as    a “Consider”, with Decision parameters Action and BidWanted derived    from the proposal properties.-   10. [Thing Only] LoadHierarchy( ), see below and FIG. 3. As    described earlier and elsewhere, loading a Thing also loads the    entire hierarchy subordinate to a Thing. It is achieved by a call to    the LoadHierarchy( ) function.-   11. [All] Processing complete, the process will return a Pointer to    the newly created memory object.    LoadHierarchy( )

This is the facility to load directly a full subordinate tree, and isillustrated in FIG. 4. Note that Section I comprising Steps 1 to 5processes the intermediate entity types Assignment, Tender and Proposal.Section II comprising Steps 6 to 9 processes the entity type Decision.

Arguments: The ID (ThingID) of the Thing Whose Hierarchy is to beLoaded.

The process needs to load all the Assignments, Tenders and Proposalsassociated with a Thing. It does this by Registering the Entities. Theprocedure is described therefore as follows.

Section I.

-   1. [Not Thing, Not Decision] The process initiates a sub-process for    each intermediate EntityType in turn. The hierarchy subordinate to a    Thing is being loaded, so Thing is redundant and excluded. Decisions    are treated differently, later, and so here excluded.-   2. Each EntityType's stored data (database table, in this    embodiment) is searched for instances of this EntityType, with the    particular Thing as their superior (ie: having matching ThingID).    For each found instance, another sub-process is initiated, which    comprises Steps 3 and 4.-   3. For each entity instance matching the Thing, the entity's    particular data is retrieved.-   4. The new data is passed as arguments in a RegisterEntity( ) call,    to load the found entity into memory. Control then passes back to    Step 2, to search for the next matching instance.-   5. Once each entity type has been fully searched, control passes    back to Step 1. If all intermediate types are complete, it passes on    to Step 6.    Section II.-   6. With the intermediate types complete, the processing of Decisions    is now initiated. A loop is initiated, wherein the Decisions table    is searched for decisions subordinate to the required Thing    (matching ‘ThingID’). For each matching decision, a sub-process is    initiated, comprising steps 7, 8 and 9.-   7. For a matching decision, the data is retrieved from the table.-   8. From the Decision's ProposalRefID Property, and following a call    to Item( ), a pointer to the Decision's Superior Proposal is    retrieved.-   9. Proposal: Math: AddDecision( ) is executed, see below and FIG. 5.-   10. Once all decisions matching the Thing have been processed, the    process is complete.    Math: AddDecision

This function is called in NewEntity and LoadHierarchy above, and isillustrated in FIG. 5 of the drawings.

Argument: None.

-   1. A determination is made as to whether the decision source is    subordinate. If it is, control passes to Step 2. If it is not,    control passes to Step 3.-   2. The procedure sets Cube=Derived Cube.-   3. The procedure sets Cube=Normal Cube.-   4. Cube:ApplyDecision( ), see below and FIG. 6. This determines the    quality and type for the selected cube.-   5. A determination is made as to whether the Decision Source is    Normal (see Steps 1 to 3). If it is, control passes to Step 6. If it    is not, control passes to Step 7.-   6. Math: Add Decision to Hierarchically Superior Entity.-   7. A determination is made as to whether the Proposal has a Sibling    Ref. If it does, control passes to Step 8. If it does not, control    passes to Step 9.-   8. Math: Add Decision (Sibling) to Sibling Proposal.-   9. A determination is made as to whether the Proposal is derived    from another Proposal. If it is, control passes to Step 10.-   If it is not, control passes to Step 11.-   10. Math: Add Decision (Derived) to DerivedFrom Proposal.-   11. Processing complete.    Cube: ApplyDecision( )

This is the facility to increment the Decision cube's data which iscalled in Math: AddDecision above, and is illustrated in FIG. 6.

Arguments: Decision parameters. Decision Quantity.

-   1. This process needs to translate the decision parameters into a    node location. It therefore iterates through each of the decision    parameters.-   2. Selecting the Decision Dimension Key for each parameter in turn.-   3. It translates the key into an index into that dimension of the    cube. (See Decision Cube.)-   4. The set of key indices thus obtained then form a vector into the    cube, so selecting a particular node in the array.-   5. The node at this key is then incremented by the noted quantity.-   6. The derived fields in the decision schema are then recalculated.-   7. The process is then complete.    Item( )

This function is called in RegisterEntity above, and is the facility toretrieve a pointer to a member entity, and is illustrated in FIG. 7.

Arguments: Entity Key

-   1. From the Entity Key supplied, the collection of similar    EntityTypes in memory is searched, to discover whether or not the    Entity is already in memory. If it is, the process moves to Step 4,    and returns a pointer to the entity.-   2. If the entity is not in memory, the process calls the Item( )    function with the Entity's ThingID to get a pointer to the superior    Thing.-   3. Since a call to Item(ThingID) always loads the full hierarchy,    subsequent new entities will also be directly loaded into memory.    Step 3 is not a process, but simply acknowledges that Thing, and its    full hierarchy, including the required Entity, will be in memory at    this time.-   4. The collection of the EntityTypes will now be searched again, and    the appropriate pointer returned to the calling function.-   5. The process is complete.    Math: GetMathvalue.

This is illustrated in FIG. 8 of the drawings. This function can becalled by a Client system, in order to find out the current status ofthe computer system.

Argument: None.

-   1. A determination is made as to whether the decision source is    subordinate. If it is, control passes to Step 2. If it is not,    control passes to Step 3.-   2. The procedure sets Cube=Derived Cube.-   3. The procedure sets Cube=Normal Cube.-   4. Cube: GetValue( ), see below and FIG. 9. The value is retrieved    from the selected cube.-   5. Processing complete.    Cube: GetValue( )

This is the facility to retrieve the Decision cube's data which iscalled in Math: GetMathValue, and is illustrated in FIG. 9.

Arguments: Decision Parameters. Decision Quantity.

-   1. This process needs to translate the decision parameters into a    node location. It therefore iterates through each of the decision    parameters.-   2. Selecting the Decision Dimension Key for each parameter in turn.-   3. It translates the key into an index into that dimension of the    cube. (See Decision Cube)-   4. CubeKey=Vector(DimensionKeys). The set of key indices thus    obtained then form a vector into the cube, so selecting a particular    node in the array.-   5. The value of the node at this cube key is then retrieved.-   6. Processing complete.

Computer Resources & Specification

While not restricted to these particular resources, the preferredembodiment of the system has been implemented on computer systemscurrently available.

The prototype of the system was developed on a 133 MHZ Pentium NotebookPC with 32 Mb RAM (random access memory), and a 2 Gb Hard Disk, runningMicrosoft Windows NT, with Microsoft Access as the Database, and withthe software developed and prototyped both in Microsoft Visual Basic 5,and Microsoft Visual C++.

The system was then ported to a Sun Microsystems Ultra5, running Solaris2.51, with a Sybase System 11 SQL Server database resource, and writtenin Unix/Ansi C++.

Thus, the key requirements of the system are readily met by theconjunction of a typical computer system, a typical software codinglanguage, and a typical database resource.

Software Design

It is readily understood that software design and implementation musttake into account the possibility of function calls failing for numerouscauses. Since this is a fundamental requirement in software engineering,which must be managed in any commercial implementation, the needs andskills appropriate to support failure will therefore be familiar to anysoftware engineer skilled in the art. As such, they do not feature as anaspect of the claims of the system, such routines and techniques fordeveloping robust code have been considered immaterial to the explicitdescription of the particular embodiment of the system.

Scope of the Preferred Embodiment

The preferred embodiment implements a fixed and limited hierarchy, ofspecified types yet which is of sufficient power to provide a modellingand management facility which will cope with typical transactions andnegotiations encompassed in the world today.

In combination with a facility to provide agents for execution ofprocesses, it then encompasses a uniform and general transactionfacility, suitable for example business, domestic, military andgovernmental use.

To the extent that these agents may themselves be computer processes,then such an environment offers a computerised transaction facility.Where these agents do not need to refer to non-computer resources fortheir information to fulfil their transactions, then to that extent, theenvironment so described becomes an automated one.

Database

For each entity type there is a corresponding database table. The tableis given the name of the entity type. Thus, the existence of a ‘Thing’entity leads to the existence of a ‘Thing’ table.

Thing Table

The Thing Table contains references to objects external to the system.Each new Thing record added to the table has a unique ThingID.

Field Name Type Notes on Usage ThingID Long Uniquely identifies a ThingClientSystem String Identifies the Client System ClientSystemReferenceLong Identifies the external object in the Client SystemClientRefDescription String Optional - Description for clientconvenience

Assignment Table

The Assignment Table contains references to processes to be applied toThing entities. Each new Assignment record added to the table has aunique AssignmentID.

Field Name Type Notes on Usage AssignmentID Long Uniquely identifies anAssignment ThingRefID Long Thing this Assignment is for InstigatorString Supplied by client to identify who created entity InstigatorRefLong Supplied by client as external reference to InstigatorPredecessorAssignmentRefID Long Redirection String Precise nature ofassignment Quantity Double How much of the redirection is requested Thefollowing fields can optionally be included: Deadline Date Date(including time) by which an assignment must be complete PreferredByDateDate Date (including time) by which it would be preferred to have theassignment complete

Tender Table

The tender table contains the information which groups proposals. Eachnew Tender record added to the table has a unique TenderID.

Field Name Type Notes on Usage TenderID Long Uniquely identifies aTender ThingRefID Long Thing this Tender is for AssignmentRefID Long Thesuperior Assignment in the hierarchy Instigator String Supplied byclient to identify who created entity InstigatorRef Long Supplied byclient as external reference to Instigator Quantity Double How much thistender relates to

Proposal Table

The Proposal contains details of the negotiation with an agent toperform the process. Each new Proposal record added to the table has aunique ProposalID.

Field Name Type Notes on Usage ProposalID Long Uniquely identifies aProposal ThingRefID Long Thing this Proposal is for AssignmentRefID LongThe superior Assignment in the hierarchy TenderRefID Long The superiorTender in the hierarchy Instigator String Supplied by client to identifywho created entity InstigatorRef Long Supplied by client as externalreference to Instigator SuperiorProposalRefID Long SiblingProposalRefIDLong Upline String Who has an interest in the process being performedDownline String Who will perform the process GoingUp Boolean Whoinitiated the proposal BidWanted Boolean Does acceptance grant right toact Action String The action in regard to performing the processConsiderQuantity Double How much of the action is proposed The followingfields can optionally be included: ReplyRequiredByDate Date Date bywhich the right to make a decision (particularly accept/decline) expiresCompletionRequiredByDate Date Date by which the accepted quantity mustbe complete

Field Name Type Notes on Usage DecisionID Long Uniquely identifies aDecision ProposalRefID Long Uniquely identifies a Proposal InstigatorString Supplied by client to identify who created entity InstigatorRefLong Supplied by client as external reference to InstigatorConsiderQuantity Double AnnulQuantity Double Amount of original proposalwithdrawn DeclineQuantity Double A response, Amount declined fromproposal AcceptQuantity Double A response, Amount accepted from proposalForwardQuantity Double A response, Amount forwarded from proposal

Instigator and Instigator Reference

At the creation of an entity record, the client system can provide tworeferences. One is the instigator of the entity creation, and the otheris a meaningful reference to the instigator.

These fields are available for each entity type, however, they are ofparticular significance to the creation of Thing entities.

Decision Schema

The preferred embodiment implements a three-dimensional decision schema,with dimensions: Action, Authority and Resolution.

Direct fields:

Direct fields represent the immediate description of the decision. TheIndex for each dimension in this embodiment is noted in brackets.

Action: [0] Do: The potential exists that something be done. [1] NotDo:The potential no longer exists for something to be done. [2] Done: Theclaim is that something has in fact been done. Resolution: [0] Consider:It is being put to an agent to (action) something. [1] Annul: The(action) is no longer available for consideration. [2] Decline: Theagent declines to pursue the action. [3] Accept: The agent accepts topursue the action. [4] Forward: The agent accepts the responsibility forthe action but will not perform the action. Authority: [0]FullAuthority: Upon acceptance, the agent is free to pursue the action.[1] BidWanted: There is no authority to pursue the action.Notes to clarify the above:

-   Consider—the preferred embodiment embeds this in the proposal. It is    necessary for the logical process that it be part of the decision    schema, but it more naturally represents the opportunity or quantity    to be decided upon.-   Annul—allows the modelling of the withdrawal of an offer, rather    than the offer being declined by the invitee.-   Forward—allows the modelling of the situation where a salesman    accepts a client order, but will not be fulfilling it himself. It    will be fulfilled, for example, by the factory floor.-   BidWanted—allows a tender for a contract to be modelled, or an offer    of tickets, where the final allocation will be at the discretion of    the offeror, not the bidder.    In the following, these are written in the order:    Resolution.Action.Authority.    Derived Fields:

Given the events (decisions) it is then appropriate to ask what thecurrent situation is. The creation of derived fields therefore allowslogical processing or mathematics to be done on the direct fields. Thepreferred embodiment implements the following derived fields.Calculations to generate the derived fields are noted beside the fielddescription. The Identifiers are taken to indicate the values orquantities associated by those identifiers.

For example: (Do−NotDo−Done=Open) should be read as: If quantityrequired as “Do”=12, and quantity to “NotDo”=5 and quantity claimed as“Done”=3, then the quantity remaining “Open” is 12−5−3=4, ie 12 minus 5minus 3. Dimension Indices are in brackets.

Action [3] Open: (Do - NotDo - Done) Everything not cancelled orcomplete Resolution [5] Available: (Consider - Annul) Everything notwithdrawn [6] Potential: (Available - Declined) Everything not declined[7] Pending: (Potential - Accept - Forward) Everything not decidedAuthority No derived fields

EXAMPLES

Natural examples of decisions which may be expressed in this schematherefore are:

Accept.Do Accept to do something. Decline.Do: Decline to do something.Extending slightly: consider the following. Accept.NotDo Accept to NotDosomething (eg: cancel an order) Decline.NotDo Declines to NotDosomething (eg: too late to cancel.) Consider further: Accept.Done:Accepts that something has been done. Decline.Done: Decline to recognisethat something has been done.

In the context of the system, a Do recognises the intent or potential toDo something, so that to Accept.Do for example sets up an expectationthat whatever is being referred to will in due course be done.

To recognise a Do is therefore to OPEN a potential. To CLOSE apotential, so that it can be dismissed from attention, one of two thingsmust happen. Either it will in due course be Done or a subsequentagreement will be set up to NotDo that which is being referred to.

The set [Do, NotDo, Done] therefore reflects a fundamental and naturalset of potential intents, actions or claims. Given a potential thatsomething can be done, so the process is initiated or OPENED as a Do;and it remains OPEN until either there is a matching NotDo, or it isDone. Whereupon it is in effect CLOSED and requires no furtherattention.

In the example outline above the decision cube will have dimensions [4][8] [2] and each element of the array will be initialised to zero.

Worked Example

This will apply 2 decisions to a Cube. The first will reflect askingsomeone to consider doing 12 of something (buying 12 bottles of water,for example). The second will reflect the agreement of the individual tothe proposal. The details of the nature of the transaction are notstored in nor relevant to either the cube or the system itself. Rather,only references to the existence of the transaction are stored. Thesystem manages and captures the complexity of the negotiation, butleaves the description of the transaction to the client system.

Decision 1: Asking someone to consider doing 12 of something. DecisionSpecification: Narrative/Intuitive description: Resolution: CONSIDERPlease consider the following proposal Action: DO to do Quantity: 12 12(of something) Authority: FULL with my permission to proceed, if youaccept.Cube Vector:

-   (Do=0, Consider=0, Authority=0): Vector=(0, 0, 0).    Cube Node:-   The active node is therefore Cube[0] [0] [0].-   Incrementing the value: the node's value is increased by the    decision quantity.-   Cube[0] [0] [0]=Cube[0] [0] [0]+12;-   The node Consider.Do.Full is now 12.-   Recalculation of the derived fields-   Only a typical case is shown here, for illustration.-   Available.Do.Full=Consider.Do.Full−Annul.Do.Full=12−0=12

Decision 2: The invitee accepts 8 of the proposal Decision Type:Accept.Do.Full Decision Quantity: 8 Decision Vector: [Do = 0] [Accept =3] [FullAuthority = 0]Implementation:

-   Cube[0] [3] [0]=Cube[0] [3] [0]+8;-   Restricting to the Do.Full indices, the Resolution dimension    therefore now looks as follows:

Resolution Quantity Consider 12 Annul 0 Available 12 Declined 0Potential 12 Accept 8 Forward 0 Pending 4

For a given Action therefore, 2 key foci exist:

-   How much has been Accepted; and how much is still Pending.-   The first acknowledges a commitment to something, allowing planning.-   The second, unresolved but potential commitments, require follow-up.

Further Embodiment

The system itself is not limited to or by the preferred embodiment. Amore sophisticated embodiment may be implemented without impinging uponor materially reshaping the fundamentals of the system herein described.Some of the additions to the preferred embodiment are now outlined.

Entity Properties

The system may include the entity property EntityCreatedAT to store itsTIME of creation.

The system may include the entity property EntityVoid to support afacility to remove an Entity from consideration, in effect deleting itwithout actually removing it from the database.

The system may include the entity property EntityClosed to enable aclient to decide not to post any further transactions to that entity.Note that this restriction would not be controlled by the system but bythe client system, otherwise it violates the ‘Reflect don't Control’principle of the system. Additional properties which suggest internalcontrol should be avoided or renamed.

An Assignment entity may include further information above and beyondthe simple identification of the transformation. For example, if afurther embodiment of the system were to support deadline modelling, adeadline for the Assignment might be further included as a field in theAssignment entity.

Audit Trail

The system may include an audit trail to record the details of alltransactions passing through the system.

Math in Memory

The system may include storing the complex calculations in memory tospeed up the overall performance.

Addition Functions for Client Systems

The system may include further facilities to enrich the range of thefunctionality available to the client system. An example is a queryfacility, taking advantage of the fact that the storage of theembodiment is a database, so that client applications may implementqueries such as:

Assignments outstanding: Assignments not Closed, Pending non-zeroAssignments overdue: Assignments not Closed, Created before X DateAgreements in place: Proposals with Downline = Y

Deleting Entities

The system may include a facility to delete entity data. In thepreferred embodiment no such facility exists. It is a design principlethat the system does not ‘forget’ or ‘lose’ information. The preferredembodiment regards data deletion, therefore, as an internal housekeepingfunction for the user.

Clearly, on limited capacity machines, an unconstrained policy of addingdata without any facility for deletion will overwhelm the resources atsome point. Therefore, a policy on deletion of data would be prudent.This will typically depend on the rate of accretion of new data, theimportance of the data, the resources available, and policy on datastorage, archiving etc.

1. A uniform and generalized transaction modelling computer systemoperable with a separate client system and adapted to performnegotiation and decision functions related to a transaction, the systemcomprising a processor and a computer-readable storage medium, thecomputer-readable storage medium providing locations for a plurality ofentities, the entities being accessible to the processor, and theentities including at least one entity of each of the following forms: afirst entity (Thing entity) having the properties of identifying aclient system and uniquely identifying using a client system referencean object in that client system; a second entity (Proposal entity)created by the client system for defining a transaction, the secondentity being subordinate directly or indirectly to a first entity andhaving the properties of identifying at least one external agent tocarry out a transformation in relation to the first entity and ofidentifying at least one counter-party to the transaction; and a thirdentity (Decision entity) capable of communicating with a second entityand having the properties of defining the types of decision that may bemade including at least a decision to accept and a decision to declinethe transaction, and determining the responses in relation to thosedecisions.
 2. A computer system according to claim 1, further comprisingat least one fourth entity (Assignment entity) subordinate to anassociated first entity, the fourth entity having the properties ofuniquely identifying the associated first entity, and identifying aparticular type of assignment or transformation to be applied to thefirst entity.
 3. A computer system according to claim 2, in which thefourth entity also identifies a quantity.
 4. A computer system accordingto claim 1, in which an agent identified by the second entity includesat least two parties to a transaction.
 5. A computer system according toclaim 4, in which the second entity additionally identifies thedirection of negotiation between the parties.
 6. A computer systemaccording to claim 1, wherein there are a plurality of second entities,one of which (Subordinate Proposal entity) is subordinate to anothersecond entity and includes the property of identifying the second entityto which it is subordinate.
 7. A computer system according to claim 1,further comprising a plurality of associated second entities (SiblingProposal entities) all of which are directly subordinate to said secondentity or to another associated second entity and each including theproperty of identifying the second entity to which they are subordinatewhereby the said associated second entities include quantities whichtogether correspond to the quantity of the said second entity to whichthey are subordinate.
 8. A computer system according to claim 1, inwhich the third entity is multidimensional and contains multidimensionalvectors indicative of values resulting from an associated second entity.9. A computer system according to claim 8, in which at least one thirdentity is a partial entity indicating a partial response from a secondentity.
 10. A computer system according to claim 1, wherein there are aplurality of second entities and further comprising at least one furtherentity (Tender entity) associated with a plurality of second entitiesand a single first entity, and identifying at least a quantity.
 11. Acomputer system according to claim 1, in which the system does notvalidate data input into the system.
 12. A computer system according toclaim 1, in which the system provides for at least the followingfunctions: (i) creation of a new entity, (ii) loading a selected entityor entities into a working memory of the computer system, (iii)incrementing a multidimensional array, (iv) retrieving a value from anentity, and (v) advising the client system of an event.
 13. A uniformand generalized transaction modelling computer system operable with aseparate client system and adapted to perform negotiation and decisionfunctions related to a transaction, the system comprising a processorand a computer-readable storage medium, the computer-readable storagemedium providing locations for a plurality of entities, the entitiesbeing accessible to the processor, and the entities including at leastone entity of each of the following forms: a first entity (Thing entity)having the properties of identifying a client system and uniquelyidentifying an object in that client system; a second entity (combinedProposal/Assignment entity) created by the client system for defining atransaction, the second entity being subordinate to a first entity andhaving the properties of (i) identifying at least one external agent tocarry out a transformation in relation to the first entity andidentifying at least one counter-party to the transaction, and (ii)uniquely identifying the associated first entity, and identifying aparticular type of assignment or transformation to be applied to thefirst entity; and a third entity (Decision entity) capable ofcommunicating with a second entity and having the properties of definingthe types of decision that may be made including at least a decision toaccept and a decision to decline the transaction, and determining theresponses in relation to those decisions.
 14. A uniform and generalizedtransaction modelling computer system operable with a separate clientsystem and adapted to perform negotiation and decision functions relatedto a transaction, the system comprising a processor and acomputer-readable storage medium, the computer-readable storage mediumproviding means for storage of a plurality of entities, the entitiesbeing accessible to the processor, the system comprising: first meansdefining a first entity (Thing entity) having the properties ofidentifying a client system and uniquely identifying an object in thatclient system; second means defining a second entity (Proposal entity)for defining a transaction, the second entity being subordinate directlyor indirectly to a first entity and having the properties of identifyingat least one external agent to carry out a transformation in relation tothe first entity and of identifying at least one counter-party to thetransaction; and third means defining a third entity (Decision entity)capable of communicating with means defining a second entity and havingthe properties of defining the types of decision that may be madeincluding at least a decision to accept and a decision to decline thetransaction, and determining the responses in relation to thosedecisions.
 15. A computer system according to claim 14, furthercomprising at least one fourth means defining a fourth entity(Assignment entity) subordinate to an associated first entity, thefourth entity having the properties of uniquely identifying theassociated first entity, and identifying a particular type of assignmentor transformation to be applied to the first entity.
 16. A computersystem according to claim 15, in which the fourth entity also identifiesa quantity.
 17. A computer system according to claim 14, in which anagent identified by means defining the second entity includes at leasttwo parties to a transaction.
 18. A computer system according to claim17, in which the means defining a second entity additionally identifiesthe direction of negotiation between the parties.
 19. A computer systemaccording to claim 14, wherein there are a plurality of means defining asecond entity, one of which (Subordinate Proposal entity) is subordinateto another second entity and includes the property of identifying theother second entity to which it is subordinate.
 20. A computer systemaccording to claim 14, further comprising a plurality of means definingassociated second entities (Sibling Proposal entities) all of which aredirectly subordinate to said second entity or to another second entityand each including the property of identifying the second entity towhich they are subordinate whereby the said associated second entitiesinclude quantities which together correspond to the quantity of the saidsecond entity to which they are subordinate.
 21. A computer systemaccording to claim 14, in which the third entity is multidimensional andcontains multidimensional vectors indicative of values resulting from anassociated second entity.
 22. A computer system according to claim 21,in which at least one third entity is a partial entity indicating apartial response from a second entity.
 23. A computer system accordingto claim 14, wherein there are a plurality of means defining a secondentity and further comprising at least one means defining a furtherentity (Tender entity) associated with a plurality of second entitiesand a single first entity, and identifying at least a quantity.
 24. Acomputer system according to claim 14, in which the system does notvalidate data input into the system.
 25. A computer system according toclaim 14, in which the system provides for at least the followingfunctions: (i) creation of a new entity, (ii) loading a selected entityor entities into a working memory of the computer system, (iii)incrementing a multidimensional array, (iv) retrieving a value from anentity, and (v) advising the client system of an event.
 26. A uniformand generalized transaction modelling computer system operable with aseparate client system and adapted to perform negotiation and decisionfunctions related to a transaction, the system comprising a processorand a computer-readable storage medium, the computer-readable storagemedium providing means for storage of a plurality of entities, theentities being accessible to the processor, the system comprising: firstmeans defining a first entity (Thing entity) having the properties ofidentifying a client system and uniquely identifying an object in thatclient system; second means defining a second entity (combinedProposal/Assignment entity) for defining a transaction, the secondentity being subordinate to a first entity and having the properties of(i) identifying at least one external agent to carry out atransformation in relation to the first entity and of identifying atleast one counter-party to the transaction, and (ii) uniquelyidentifying the associated first entity, and identifying a particulartype of assignment or transformation to be applied to the first entity;and third means defining a third entity (Decision entity) capable ofcommunicating with means defining a second entity and having theproperties of defining the types of decision that may be made includingat least a decision to accept and a decision to decline the transaction,and determining the responses in relation to those decisions.
 27. Auniform and generalized method of programming a computer as atransaction modelling system, the computer system being operable with aseparate client system and adapted to perform negotiation and decisionfunctions related to a transaction, the method comprising the steps of:providing a computer system comprising a processor and acomputer-readable storage medium, the computer-readable storage mediumproviding locations for a plurality of entities, the entities beingaccessible to the processor; generating with said processor on saidcomputer-readable storage medium a first entity (Thing entity) havingthe properties of identifying a client system and uniquely identifyingusing a client system reference an object in that client system;generating with said processor on said computer-readable storage mediumand using said client system a second entity (Proposal entity) fordefining a transaction, the second entity being subordinate directly orindirectly to a first entity and having the properties of identifying atleast one external agent to carry out a transformation in relation tothe first entity and of identifying at least one counter-party to thetransaction; and generating a third entity (Decision entity) capable ofcommunicating with a second entity and having the properties of definingthe types of decision that may be made including at least a decision toaccept and a decision to decline the transaction, and determining theresponses in relation to those decisions.
 28. A computer program productdirectly loadable into the internal memory of a digital computer, andcomprising software code portions for causing the computer to become acomputer system in accordance with claim 1 when the product is run on acomputer.
 29. A computer program product directly loadable into theinternal memory of a digital computer, and comprising software codeportions for causing the computer to become a computer system inaccordance with claim 14 when the product is run on a computer.